To: Lisa 1.75 Meeting Attendees 
From: Paul Baker 

Date: May 26, 1983 

subject: Minutes of 5/5/83 sla 
cc: W. Rosing DM 
The following issues were discussed at the ries 1.75 meeting on May S, 1983: 
1 - Next Meeting would be 5/26, same time same place. 


.2 - The ERS was discussed, clarification-on the lack of battery backup was 
Suggested, it will be added in the third draft. More discussion of the ERS 
follows below. 


3 - The operating assumption. for the deco is that the current apps and bigh 
level OS parts will work on both machines without changes. 


4 - A working group to discuss the widget/1. 75. interface was formed, minutes of 
the first meeting are attached. 


5 - The location of the serial number is still an 1 open issue . 


6 - The comment was made that due to the fact that the 68K is doing the motor 
stepping, it is important to service the Timer 1 interrupt promptly. 


7*- § question was raised regarding parity checking on DMA. In addition some 
questions were asked about the use er the two new expansion slots. The new ERS 
addresses these issues. 


8 - Questions were asked about the COPS/NI/Reset ideas . Tne new ERS addresses 
this issue. 


9 - The twiggy use light is still an issue. 


10 - Issues of compatibility between Lisa 1 and Lisa 1.75 I/0 expansion cards 
were raised. Engineering committed to write an application note so designers 
could design cards that will work in both systems. 


11 - Service indicated that they would like mockups to evaluate servicability 
aspects of the system and that they would like to be involved in production 
philosophy discussions. Service indicated that they also need a PIP so they can 
scnedule their activities. They indicated tnat they would need schematics by 
7/28, 2 systems with socketed components by 10/28 and 3 final systems by 11/28. 


12 - A remaining open issue is the relationship between Lisa 1.75 and the file 
server. | | 


To: Ken Okin~ 

From: Paul Baker 

Date: May 6, 1983 : 

Subject: First Widget Meeting minutes 


cc: W. Dirks, R. Monhme G. Marten, B. Lee, W.. Henry, D0. offen, M. Urqnart, 
C. Twyman : 


The first Widget/Lisa 1.75 meeting was held nay 5 and the following issues were 
raised: 


1 - Current status is: 30 drives on test using 16 sector controller, about 70 
drives total have been built, build rate is now about S50/month, going to 
100/month saon, 500/month in August and 3000/month (maybe) in October. The 
nineteen sector controller is working now, still waiting for ECC gate array, 
still waiting for second pass main gate array. We can expect a working 
drive/controller with firmware on 7/1. 


2 - The drive was designed with performance in mind, average access is 55 ms vs 
180 ms on the Seagate, track to track is 7 ms vs 20ms. Latency is higher at 19 
ms max vs 16 ms. The data rate is 5 MHz. The 20 MB widget will have higher 
latency of about 25 ms max and a slightly higher data rate of about 6.5 MHz. 

The 40 MB widget will have still higher latency and a higher data rate in the 
7-8 MHZ range. These futures issues are important if we are to accomodate the 
new drives in the Lisa 1.75. Are we? (open issue) 


3 - The widget firmware has about 600-750 uS of overhead on a one sector 
transfer. The goal is to get this to 500 uS. On @ multi sector transfer the 
overhead will be less per sector, about 400 uS. Lisa 1.75 should be able to 

_ Maintain a 1 Mbyte/sec transfer rate so about 500 uS will be used to transfer 
data. Based on this we have decided tenatively to use the Profile+ controller 
circuit as is in the Lisa 1.75. The OS mostly issues multi sector disk commands 
so the reduced overhead should make it possible to achieve a 2:1 interleavé. 
.Using the same controller in both Lisa and PCS should reduce the design time. 
The format of the multi sector commands is that a single command will cause 
multiple sectors to be transferred with an interrupt on each sector and status 
on each sector. An error in a multi sector-transfer will abort the transfer. 
If Lisa is unable to keep up with 2:1 interleave we will use 3:1. Both PCS and 
Lisa drives will be formatted tne same, PCS will nave to live with whatever we 
can accomodate. Wolfgang says they think 5:1 is great. 


4 - The controller firmware has two layers, one at the high level that only 
performs read, write and write verify, and a low level that performs all the 
operations that are requried to perform the high level commands. Both levels 
are available to the user of the drive, so diagnostics can use the low level 
commands, but if the user uses the low level commands he is responsible for 
maintaining consistency on the media! The controller also supports ECC but the 
correction is done in firmware so it is slow. The idea is that tne ECC will be 
used in conjunction with the track sparing so a block that is damaged should be 
spared without data loss. The ECC can handle burst errors of up to 11 bits. 


5 - A fair sized issue relating to the operation of the Profile+ with Lisa 1 
came up. The issue is that since the interleave is different and since there 
are 19 sectors per track it will be difficult to do the sector mapping as. we do 
on the Profile, we may have lower performance on the Profile+. Dave Offen will 


have to determine the ramifications of this. (open issue) 
6 - There was some discussion about cooling, air moving and mounting the 


controller card on the disk. This is all left open until POS can staff up a 
product designer for Lisa 1.75. (open issue) 


The next meeting will be May 26 ant 3:30. . 
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14,75 ERS - 
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The current SO0 chip self test actually lets data-thru the chips 
gutput ports. We need ah additional butter off the output which 
can be disabled dur ing this teat, 


Ta diagnose MMLUS probleme, what would be ideal is if th 


ae er INE OR 
war toa latch an address thakt was decaded bor alae MMU from eo 
to a physical address. By Knowing. the physical addres: that the 
MMU Kas converted a much better diagnostic pected be possible. 
This would require a method of oe when to latch the address 
and & way ta read 


the latched address 
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